1. Technical Field of the Invention
The present invention generally relates to presence. More particularly, and not by way of any limitation, the present invention is directed to system and method for indicating network quality of service (“QoS”) capability as an end-user presence attribute.
2. Description of Related Art
With today's widespread use of the Internet as a major communication medium, data communication devices are now being designed so that they are capable of communicating over packet-switched networks. For instance, telephones, pagers, personal digital assistant devices, cell phones, handheld computers, and even fax machines can now be accessed and controlled from the Internet. Communication over a packet-switched network using communication devices that traditionally communicate over a circuit-switched telecommunications network is generally known as network telephony, or IP telephony when an IP network is involved.
Various types of user communication devices (e.g., a cell phone, laptop or handheld PC, desktop PC, and the like) can identify themselves to the network using a suitable identifier (e.g., username@company.com). “Presence” refers to, for example, the availability, proximity, activity level or operating state of a user on a network. The ability for users to monitor each other's presence is a feature offered in connection with many applications that support network telephony. For example, instant messaging applications such as MSN® or Yahoo® have an “available buddy” feature, in which a user of the application can determine whether select users are available for engaging in communication. The data retrieved and returned to the buddy list, e.g. “John OFFLINE” or “Susan ACTIVE”, is known as “presence information,” and is generally maintained by a presence server in the data network, often a dedicated server. Typically, the presence server supports network telephony protocols such as the Session Initiation Protocol (SIP). Users can register their communication devices with the presence server in order to have their presence maintained and to allow various programs on the network to facilitate network telephony services. A first device user wishing to detect the presence of a second device user does so by “subscribing” with the presence server, such as via a SIP SUBSCRIBE message. The presence server intermediates between the first device user (also known as the watcher or subscriber) and the second device user to facilitate the communication of the second device user's presence information to the first device user.
Additional details about presence and presence modeling are set forth in the Internet Engineering Task Force (IETF) Request for Comment (RFC) 2778 entitled “A model for Presence and Instant Messaging,” dated February 2002; RFC 2779 entitled “Instant Messaging/Presence Protocol Requirements,” dated February 2002; and Internet-Draft identified as <<draft-schulzrinne-simple-rpids-01.ps>> and entitled “RPIDS—Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP),” dated Feb. 18, 2003, which are incorporated herein by reference.
It is commonly known that real-time multimedia interactive communications are very sensitive to the Quality of Service (“QoS”) provided by the underlying converged IP network. For example, applications such as on-line gaming and voice-over-IP (“VoIP”) cannot be reliably offered as a revenue generating service without being able to provision the network for meeting the bandwidth, delay, and jitter requirements of such traffic.
Presence-based personal communication is gaining momentum. Currently, commercial systems implementing presence-based communication technology revolve around simple “buddy list” attributes that display the availability of the communicating parties. Trends in next-generation systems are quickly evolving into a rich presence-enabled communication where general capabilities, device information, and other environments of the buddies are becoming important presence attributes. None of today's definitions of rich presence information explicitly consider network QoS capability as an attribute. Before a caller initiates a session of an application like on-line gaming and VoIP, he must attempt to infer the QoS capability of the callee access network from information such as the callee's device type and the wired/wireless attachment of the end system to the network. This is by no means an accurate indicator of the QoS state of the underlying IP network between the caller and the callee.
Currently, there are basically three solutions to this problem. In a presence-based communication environment, the watcher tries to infer the QoS capability of the presentity from the end-system information, such as terminal type and the terminal attachment to the network as wired/wireless. In a non-presence-based communication environment, end-users typically have to negotiate for network QoS using complex protocols, like RSVP. Finally, the most common practice is to initiate the communications session and hope for the best.
Each of the so-called “solutions” set forth above suffer deficiencies. The first does not in any way take into account the QoS capability of the network itself. The second has been found not to be widely deployable because of its complexity. Moreover, even if it were to be deployed, the QoS information resulting from the solution is not available before the initiation of the session. The third will work only in an over-provisioned network; otherwise, it is very difficult to deploy a reliable service over such a system.